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Digital lights management system 



JNIRODUCn-ION TO THE INVWriON 

In recent years, tbe amount of content protection sj^ems is growing in atapid 
pace. Some of these systems only protect the content against illegal copying, while otiiers ate 
also prohibiting the user to get access to tibe content The first category is called Copy 
5 Pirotection (CP) ^ystraos. CP systems have traditionally been the main &cu8 fbr consumer 
electronics (CB) deviceSi as this type^ content protection is thought to be cheaply 
impl^ented and does not need bi-directional interaction witii the content provider. Some 
exansples are 11]ie Content Scrambling System (CSS), the protection system of DVD ROM 
discs and DTCP» the protection system £1^ IBEE 1394 conneotians. 

1 0 I%ie second category Is Icnown under several names. In the broadcast wGarld, 

systems of this category axe generally known as conditional access (CA) systems, while in 
ihe bitemet world they are generally known as Digital Ri|phts Management (DKM) systems. 

Some i^e of CP systems can also fnovide services to interfacing CA or DSM 
systems, l^amples are ^e systems currently under development by th&DVB^T subgroup 

15 andth&TV-AnytimeRMP gn>up. The goal is a system in which a set of devices can 

authenticate each other trough a bi-dkectlonal connecticni. Based pn this anfhenticationo the 
devices will trust each other and this will enable/aUow ISbem to exdbiange protected content. 
The accompanying licenses descnbe which rights tbe user has and what operations he is 
allowed to perform on the content The license is protected by means of some general 

20 network secret which is only exchan^ between the devices within a certain household. 
This network of devioes is called an Authorized Domahi (AD). 

The concept of au&oxized domams tdes to find a solution to both save the 
interests of the content cvmers (that wjint protection of their copyrights) and the content 
consumers (that want unrestricted use of the content). The basic principle is to have a 

25 controUed network environment in which content can be used relatively fteely as long as it 
does not cross the border of the authorized domain. Typically^ authorised domains are 
centered around the home environment, also referred to as home networks* Of course, other 
scenarios ate also possible. A user could for example take a portable television with him on a 
trip, and use it in his hotel room to access content stored on his Personal Video Recorder at 
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home. Even thougli the portable telervision is outside the home network, it is a part of the 
user's authorized domah. 

A home network can be defined as a set of devices that are interconnected 
-iisiiig-some-kind.ofnetwork4eclmology-(^.^^^ 



5 Although network technology allows the difiFerent devices to communicate, (his is not enou^ 
to allow devices to int^perate. To be able to do this, devices need to be able to discover and 
address the fbuctlons present in the otider devices in the netwotk. Swh intexoperabiUty is 
provided by home networking middlewaie (HN-MW). Bxanqjles of home netwojklng 
middleware are Jini, HAVi, UPnP, AVC . 

10 From a HN-MW point of view, systems related to handling secure oontettt 

s^pear in several ways. Certain fimotions in the netwcxck require access to protected contdnt 
Other functions in the network provide fimctionality that can be used by the elements hi the 
network handling content security. Fuifhemiore, security fiameworks like OPIMA can use 
the HN-MW to locate each ofher and communicate ia an interoperable way. Of course 

15 aodiorized domains can also be implemented in other ways. 

For amore extensive introduction to the use of DKM in homo networks, see 
FX.Ai J. R:an9>eQcman, S AJP^A, van den Heav^ MJB!. Verberkt, Z>igital Rights Managcanent 
in Home Networks, Philips Research, The Netberimds, IBC 2001 con&renoe publication voL 
]; pages 70-77. 

20 Various systems already exist that inclement Ihe concept of authorized 

domains to some extent Examples of such systems are SmatfRigjht (Thomson Multimedia^ 
xCP (4C mainly IB;M)3 andNetDBM(Matsfaushita). , 

SIJMMARY OF THE INVENTS 
25 It is one object offbo invention to provide an Authorized Domain (AD) 

management mechanism in a DRM system that supports: 

• Creation and Setting up of an AD 

• Verification of AD device compliancy ..... ^ ... . ^ . 

• Verification of AD membership 

30 • Secure handling ofcontent and rij^t^ transport 

• Secure handling of contmt and dgbts (local) storage 

The solution involves ihe following components: 

• A specific certificate chain 

• A specific certificate and key registration in devices 




006 23.09.2002 15:02 



3 



23.09-2002 



# A spedfiQ device architecture 

• A specdfio set of certificate xnanipulatioQS to suppoit AD ixumagemeot cperatfoDS, suctai as 



5 certificate diaiii Hiat governs device compUancy and domain (de)regi$ti:atlon. This specific 
eet-iQ), in ccnnbiixation vtdth Ibe strict separatLon between content axid liceEises, also allows a 
large nmnber of domain operations without interjference of the domain managers and as such 
si^orts difi^eot distribution schemes, such as for sample scqper distribution. 



10 1. AX> creation 

2. Eiiti1yoheok-in/obeck-<)ut(» 
medium). 

3. AD seouti^ features for content and li^tesdi^ 

4. DRM fimctionalities 

15 The AD creation is liie action by which a new AD is created. The emtity check- 

in/dieck-out is the action by which a new entity can euteir/leave the AD. The AD security 
features relate to all the means that are necessary to ensure a $u£Gieient seouiity level in the 
AD. The DRM functionalities are the rules, which govern content u^e and right exchanges 
within the AD and between different ADs. This implementation describes solutions for all • 

20 the^e points. 

BRIEF DESCRIPTION OF THE PIGIORES 

These and oilier aspects of the invention will be apparent firom and elucidated 
with reference to the illustrative embodiments shown in the drawings, in which: 
25 Fig. 1 schematically shows a system conxpiising devices interconnected via a 



AD set-up^ device 6hed&in» content check^in, etc. 

The invention mainly charaotedzes itself through the u^e of a ^ecific 



In a woiidng AD inqsilementation, at least the following points mnst be solved: 



network; 



30 



Fig. 2 schematically shows a configuration of a simple device; 

Fig. 3 schematically shows a configuration of an enhanced device; 

Fig. 4 schematically shows a configuration of an authorisiod domain manager. 

Fig, 5 sdiematically shows a configuration of a device managec; 

Fig. 6 schematically shows a configuration of a rights manager; 

Fig. 7 schematically shows a configuration of a content manager, 

Fig. 8 schematically shows a certificate chain; 

Fig. 9 illustrates which elensients are stored in a device; 
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4 23.09^002 
Fig< 10 suxnmaiizes which d^^ite ai^ stoTcd in a device which is part of an 
existing AD; and 

Fig. 11 iUustrates the cheok-in of a device in the AD. 



5 corresponding features. Some of fhe features indicated in the drawings are typically 

implemented in software, and as such represent software eoiitiea, such as software modules 
or objects. 



SYSTEM ARCHITECTURE 
10 Fig. 1 sdiematically shows a S3^tem 100 comprising devices 101-lOS 

izifeirconneoted^da anetwozk 110. In 1^ 

n^ork. A lypical digital home network includes a number of devices^ e.g. a radio reodvery a 

tuneo/deooder^ a CD player* apair of speakers, a television^ a VCR, a tapo decK and so on. 

These device are usually intercoimected to allow one device, e.g. the television, to control 
1 S anotber, e.g. the VCR. One device sudh as e.g. the tuner/decoder or a set top box (STB), is 

usually the central device, providing central control over the others. 

Cont^t, which typically comprises things like music, songs, movies, TV 

programs, pictures, books and the likes, but which also includes interactive services, is 

received through a residential gateway or set top box 101. Content could also enter the home 
20 via other sources, such a3 storage media as discs or using portable devices. The source could 

be a counectipn to. a broadband cable nBtwodc, an Int^net connection, a satellite downllzUc 

and so on. The content can then be transf^ed over the network 1 10 to a sink for rendering. 

A ainlc can be, for instance, the television display 102, the portable display device 103, the 

mobile phone 104 and/or the audio playback device 105. 
25 The exact way in which a content it^ is rendered depaids on fhe type of 

device and the type of content For hastance, in a radio receiver, rendering comprises 

genemting audio signals and feeding them to loudspeakers. For a television receiver, 
• . — -rendering generally compiises geuerating audio and video signals and feeding those to a 

display screen and loudspeakers. For other types of content a similar appropriate action must 
30 be taken. Rendering may also include operations such as decrypting or desorambling a 

received signal, synchrouising audio and video signals and so orL 

The set top box 101, or any other device in the system lOO, may comprise a 

storage medium Si such as a suitably large hard disk, allowing tiie recording and later 

playback of received content The storage medium SI could be aPersonal Digital Recorder 
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^DR) of some kmd, for example a DVD+RW recorder, to which the set top box 101 is 
connected Content can also eoater the syst&ai 100 stored on a catrler 120 such as a Coxxxpact 
Disc (CD) or Digital Versatile Disc (DVD). 

The portable display device 103 and the mobile phone 104 are connected 
S tirelessly to Ihe network llOxising abase station 111, for ^tiample using Bluetooth or IBEB 
802.1 lb. The otb^ devices are connected using a conveaitional wired connection. To 
allow ihe deuces 101*105 to interact, several interoperability standards are available, ^v^ch 
allow dijSbront devices to exchange messages an4infonnatzon and to control each other. One 
well-known standard is the Home Audio/Video Interoperability (EAVi) standard* version 1.0 

10 of i»^ch was published in Jaxniaiy 2000> and which is available on the Intemet at ^e address 
ht^://www.havi.org/. Other weU^knbwn standards are the doihestic digital bus CD2B) 
standard* a conunnnications protocol described In 7BC 1030 and Universal Plug and Play 
(htft>:/^TOw.T5inp.oig), 

It is important to ensnrs that the devices 101-105 in the home netwodc do not 

15 make unauthorized copies of fhe content To do lhis» a security framework; typically re&n^ 
to as a Digital lUgbtsKdbnagement (DRM) syst^ is necessary. In one such firamework, the 
home network is divided conceptually in a conditional access (CA) domain and a copy 
protection (CS^) domain. Topically, the sink is located in the CP domain. This ensures that 
sufhen. contmt is provided to the sink, no unauthorized copies of the content can be made 

20 because of the copy protection scheme in place in the CP domain. Devices in the CP domain 
may comprise a storage medium to make teinporary copies, but such copies may not be 
exported fiom th« CP domain. This firamework is described in European pat^t application 
01204668,6 (attomey docket PHNLOIOSSO) by the same applicant as the present application. 
Regardless of the specific apptoaoh chosen, all devices in the in-home network 

25 that implement the security ftameworlc do so in accordance with the implonaentation 

requir^ents. Using this framework, these devices can authenticate each other and distribute 
content securely. Access to tiie content is managed by the security system. This prevents the 
unprotected contaat from leaking "in the clear" to unauthorized devices and data origmatmg 
from untrusted devices from entering the system. 

30 It is important that devices only distribute content to other devices which fiiey 

have successfiilly authenticated beforehand. This ensures that an adversary cannot make 
unauthorized copies using a malicious device. A device will only be able to successfully 
authenticate itself if it was built by an authorised manuftoturer^ for example because only 
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anfiijorisied mazni^kcturers know a particular secret necessary for successful autibtentication or 
their devices are provided with a certificate issued by a Trusted Third Party, 

Device arGhitecUire 

iOTTOriscl^lmea as a collection of devloes 12iat pejibim actions with contents according to 
S the lights, i;vMch have been defined by content owners, The devices are Ibe central point in 
this design since they are responsible fbr enforcing dghts that are bound to oantents. They 
manage ttie AD and per&tm all the DRM tasks. The devices must stiU be able to woik in an 
unconnected way^ ie. without any connection to a central server. Tbere are two types of 
devices in an AD: simple and enhanced devices, 

1 0 Simple devices do not have much storage, power or processing capacities. 

They only coatain AD Qieats, which per&rm simple DRM tasks* They can render content 
and are able to intetprct and update the corce^onding ri^ts. These are typically portable 
devices:, which are often dlsconneoted from the ADM. The configuration of a simple device 
is given in Fig. 2. The ^plication layer has been omitted in this schema, although it is 

1 5 present in every device. The difierent components are described below. 

Enhanced devices have storage^ power and processing capacities. They 
contain an additional component: the centralized version of the ADM, wMch is responsible 
fyr administrating the domain. If there is more than one enhanced device in an AD, only one 
uses its ADM functionaJitles, The oth^s behave lijce simple devices. These devices are 

20 typically set^top boxes, which are generally not moved* The configuration of an enhanced 
•deviceis givOTi'inFig, 3. ' ' " ' ' 

The users are not as important as devices. They are involved in Hie checlc- 
in/out of devices or of other users but are not ideotiSed in order to provide an easier use of 
the system. For reasons that are explained lat^, xisers are not part of this implem^xtatioa 

25 The niedia also introduce some problems because of their read/wxite 

cE^abilities. They can be seen as static components^ wMdi are only used to store contents and 
lights. They are not included in this implementatiorL 

The contents and the rights are stron^y bound. However^ in this 
implemenlatlony we c&beck them in/out andl^ep th^ s^aratdy. This lets more fireedom for 

30 later idioioes. The contents and the rights are processed by devices and are tcansfeocred 

betvtreen devices of the same AD. This transfer must be as transparent as possible to the users. 

The AnthorSased Domain Manager (ADM) participates in the check-in of 
other de^vices administrates the AD. In the present inventionj &6 ADM is centralized in one 
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single device. This should not be problematic in Ih-Home Digital Netwoik (JHDN) because 
in many sitciations» th^are is at least one device which stays in a fixed area. 

The ADM is fiie impl^xkentaiion of the domain manager and the central point 
of the AD. It is only contained in enhanced devices, Its roles are multiple: 

• Checking-in devices in die AD 
« Revoking AD devices 

• MaimaiHtig a list of devices, rights, media and contents that are in the AD. The list may 
optionally also contain the status of eveiy entity (available, unavailable, connected^ 



10 • Creating AD ceztificates for devices and if necessary. Certificate Revocation lists 
(CRLs) 

The configuration of an ADM is given in Fig. 4. The AB Certification Server 
is the Certification Authority of the AD. It issues AD certificates for AD devices and CRLs. 

The Registration Server is a service, which is used to register every entity in 
IS the AD such as cont&nt^ device^ rights or users. The devices can use it to report their content 
or ri^t lists. This component strongly collaborates vrith fixe AD Database Manager. 

The AD Database Manager manages a database that contains all the 
information related to the AD. This consists in lists of caxtitiea that are present within the AD, . 
It is accessed by devices to retrieve information about the AD, for inslance^ whm tboy need 
20 a list of aU the ri^ils or contents liiat are ci:irr6ntly avails^ 

A backup of this coraponent and of its (<mtical) information could be ieali2;ed - 
e.g, by setting 'op a master ADM and to have one or more slaves that backup ADM critical 
information in case of master &ihu:e. 

Revocation, as handled by the AD Certification S^er, can be achieved in 
25 several different manners. Two di^erent techniques would be to use so-called black lists (a 
list of revoked devices) or white lists (a list of un-revoked devices). 

In the black list scenario, the device that is to verify the trust of its 
communication partner, needs to have an up-to-date version of the list and checks whether 
the ID of the other device is on that list. The advantage of black lists is that the device are 
30 trusted by default and the trust ui them is only revoked, if their ID is listed on liie revocation 
list This list wiU be initially very small, but it can potentiaUy grow Uniestriotedly. Therefore 
both the distribution to and the storage on CB devices of these revocation lists mi^t be 
problemado in the long nm. 
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In the white list sc^ario^i a device has to patove to othei^ that it is stiU on the 
list of allowed commumoation partners. It will do tMs by presenting an up-to-4at6 version of 
a (M^ficat^ which states lhat the device is on the white list Tiie white list techniques 
apceomes the storage |noDlem» by having only a Mea lengm certiScate stored in each 
S device which proves that that device is on the white list The revocation acte by sending all 
devices, eocc^ for the revoked ones^ a new version of the white list certificale. Although 
now the storage in ihe devices is limited, the distijbuti^^ 
almost insuxmountable problem if no efficient scheme is available. 



10 PHKL020S43) provides a technique vAiixih combines the advantages of black lists (initially 
small distribution lists) with the main advantage of white lists Oimited storage), Pr^erably, 
Ibis technique additionally uses a device certificate, which proves the ID of a device, TMs 
device cortijScate is aheady present in the devices (hidependrat of revocation) as the basis &t 
the hiitial trust and is installed, e. g. » daring production in the factory. 

15 Device Manager 

The Device Manager manages all the security objects such as device certificates and private 
key and can regigt^ the device to the ADM. It is also responsible for mamtaining the 
knowledge that a device ha^ about its environment: it stores a list of connected devices and 
their respective content and rigjat lists. The configuration of the Device Manager is given in 



25 eni^yption keys or device certificates and provide them to other component, especially to 
the netwozk layer (not represented in these schemes), 

Rig|it*Man^er * - - 

The Sig^t Manager is a decentraliz;ed part of the DBM system. It is present in every device 
and provides the means to intexpret, manage and trailer rights* It interacts v^Hi the ADM for 
30 registering and locating tights. The tasks of the Right Manager include: 
• Checking-in/out rights 

« intezpretmg, updating^ deleting^ checking validity^ storing and ttan^fening rights 



European patent application serial number 02077422.0 (attorney docket 



20 Fig. 5* 



The Device Handler is ihe cdnponent that maintains all the in&rmation 
conceming the surrounding enviromneat It stores a list of devices and, optionally^ theb: 



content and ri^ lists. 

The SecnrUy Module tal^ care of all lb& security infbxmation such as 



(between devices) 
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• importiiig/exporting rights &oin/to other ADs or proprietary DRM systems 

Thdconfiguratxonof aRi^Mamgerisgiveam 6, The Ri^t Handler 
manages a local database of rights. Its tafiiks include rights retrieval, storagei and deletlozL 
When the application aska 0ie Right Manager about a right availability and/or vajidi1y» fiie 
Ri^t Handler interacts wKh the Right Processor to retrieve and interpret the ri^ 

The Sight I/O tak^ care of Ihe importation^ export aod trans^ of rights 
between devices, tts importation aad export fimctionalities can be extended ynSi Right I/O 
Phigins to enable a certain level of interoperability with other ADa or proprietory DRM 



10 The Right Processor per&rms all processing tasks relative to ri^ts, that is: 

• interpreting and iQ)dating rights 

• checking rii^validily 

• signnig rights 

• eaciypting/decrypting secret part of rights, such as content encryption keys 

15 Content Manner 

The Content Manager is very aimilar to the Right Manager in its strocture 

and tasks. Its tasks are to: 

• retrieve^ store» transfer and proc^ cont^t (with appropriate codecs) 

• enoTpt and decrypt content 

20 • insert content fix»m OA DRM systems 

• imporf/e^ort content fbcmi/to olher ADs or proprietary DRM systems 

The configuration of the Content Manager is given in Fig. 7. The Content 
Handler is vety similar to the Right Handler. It manages a local database of contents. 

The Content I/O provides the fimctionallties to transfer content between 
25 devices and to import/export content ftomAo other GA DRM systems. When transfezring 
fitun/to other proprietary systems or ADs^ it changes the content protecdon to make it 
compliant with the destination domam. In such cases^ it uses Content I/O Plugins. 

The ContaoLt Processor renders, transfomis (fixm one format to another one), 
encrypts and decrypts content (when necessary). It can also get Content I/O Plugins to 
30 extend its fimctionalities. 

DRM Module 

The DRM Module is responaible of the other tnodules inside the devices. It can handle 
opscations for cbLecMag^iii/out some media^ lights or contezits in the AD in a connectionless 
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maxiner (Le. wlien fhe ADM is not available directly). It coordinates the Emotionalities of all 
the device components. For instance, when a content is rendered, it calls the lUglit Manager 
for a valid rl^t and, if saob a li ght &sdB% extracts fhe contmt protection fix>m it Tbm^ it 
give$l^]c€^i^naie content Manager^ together witn a request to i^nder^e desired content. 

5 Certificate chain 

A certificate chain, illustrated in Fig. 8, contains the following certificates: 

1 . The (e^dmial) CA root certificate^ self-'Signed and whidi is used to sign device 
certificates. 

2. The device certificate, signed by the CA root private key and contai^oing the device 
10 prablic key, 

3. The AJy root certificate, which is generated by the ADM at AD setctp and which signs a 
new key pair. The private key corresponding to this certificate will be used to issue AD 
device certificates, 

4. The AD device certificate, issued by the ADM when the device joins an AD. 
IS The reasons tiiiat lead to this solution are: 

• It allows devices to check their respective membership without any concnection to the 
ADM, once they have registered in an AD. This way, they can safely exchange dghta 
without being connected to the ADM. 

a Regrouping or ^grouping ADs is easily ux^lem^ed, by adding one or more certificate 
20 in the certification path. Of course, this would in^ly an increased need of secure storage 
pl^ce fbr every ad<Kfional element 

• The structure is very siniple and would be suitable for small CB devices, 

• There are two ways ofremoving a device from an AD: to setup a new AD axid to refiise 
this device in this new AD, or to Issue a CRL that contains the revoked AD device and to 

25 distiibute it to an the connected devices . 

• Critioal security eleEoents such as Ihe AD root private key aire only stored in one single 
place, as opposed to ofiier solutions which require the distribution of a abated secret 
amotig a set of devices, This decrea^s the number of points of fidlure, and therefore, 
contributes to an inccease in the level of security. 

30 The certificates provide the fbllowing assurances: 

• Certificate 1 and 2 ensure device compliancy at manufkcturing time 

• Certificate 3 belongs to the AD manager and mables the creation of an AD 
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• Certificate 4 enables proving of AD membersbip l^otii online and ojQOine (refening to 
being conneoted to the AD xoanag^) 

On devlcB certificate registration 

All a&vices most cozttain the foUowing elements, vAddk are lEoeferably burned mto ROM at 
5 manufacturing time: 

1. The certificata of tiie external CA. 

2. The device ceiiificate, issoed by the external CA» containing the device identity and 
stating that the device is compliant 

3. The device private key^ corresponding to the public key signed by the external CA in the 
10 device certificate 

These con^onents are summarized in Pig. 9, They must be kept in a secure 
storage. The device public key is repre$eated» although it is already contained in the device 
c^iificate. 

In addition to these elements, a device which is part of an existing AD.also 
15 stores the following elements, aa illustrated in Fig. 10; 

1. An AD device certificate, staling that this device is part of a specific AD. This c^tificato 
is signed by the ADM and contains the device public key. 

2. The AD root eei1ifiMte,w];dch is generated by the ADM during A^ 

3. The device certifficateoflJie ADM, signed by the extern^ 

20 Hiese elmients are stored in a rewritable location, which must be secure. The 

devices that are implementing the AD management fimctionallties additionally store ^e AD ^ 
root private k^, which is used to issue AD device certificates. The coiresponding public key 
is the AD root pubUo key» contained in the AD root certificate. 

AD management operations 

25 The ADM uses a fectory-installed private key KADMrnv (synonym for Kdevphv) to create a 

local intemiediate CA. The ADM issues AD certificates for the key pairs that are already 
burned into the devices* Devices can check that they belong to the same AD by checking 
their respective AD certificates. To achieve this, they use the distributed public key of the 
AD root cextifioate. Some advantages of this solution are: 
30 ♦ KABMprfv liwer ohaftges. This avoitJs update problems (but can lower the security). 
• The system can revoke any AD entity in a very shnple way. 
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AD Setup 

The AD setup is perfbimed by an enhanced device, which iTvill be the new ADM. The device 
does the following: * ' 



S 2, It oiiBates an AD root certificate for 

private key Kadmmv 

3. It stores the created Icey pair and certificate in a secure place 

4. It initializes its databases 

5. ItasIssaiisertoenterapa$$word,P^,wMchwiUbeu&edtoadniim 

1 0 After this imtialissatioa, devices can be added by performing coocresponding 

dh»^"in operations. . * . ' 

Device Cheek-In 

The dhock-in of a device is ilhistrated in Fig. 11. Prerequisites for checking-in a device are: 
« Tbe device is connected to the ADM 
IS • A user wbo knows operates the device 

• The device can set up a Secure Authenticated ChanndL(SAQ^ 
conununioatioiL 

A SAC aIloi»^ scenic ^change of infozmation between two devices. See e.g« 
Butppean patent application aerial number 02078076.3 (attorney docket PHNL020681). The 
20 procedure is; 

1. The user asks the device to lejB^^ to the ADM 

2. The device and the ADM establish a secure authenticated diannel 

3. The device asks the user to enter P^ 

4. The device tianamitB the entered password in a join request message 

25 5, The ADM chebks the password and request and if yalid^ signs an AD certificate for the 
device public key (Kd^^a^i^ 

6. The ADMsendsthe ADcertLficate badt to the de^ - - - 
certificate (containing the AD public key Kab-puh) 

7. The device stores botli c^lificate and public keys, and the ADM device certificate. They 
30 will be needed to validate the certificate chaiu 

After this check-in operation^ the device can exchange infoxmadon with other 
devices of the AD qaing its AD certificate to prove its membership. 
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Device Oieck-Out 

A device check-out operation can occur only when a user operates a device and initializes it. 
The content and flie righte that are stored locally and protected wiOi K^ovWv 
available anymore, as long as the device does not join the domain again. 

5 Hie check-out op^ation is defined by fho initializalion process tbat is 

performed directly on them, The initialization consists only in deleting the device AD 
certificate &om the device memory. Note lhat the ADM is not involved in device check-out 
and that this operation automatically excludes the device fixm being part of the AD because 
it delete its AD certificate, 

10 A forced check-out of an AD device out of the AD is also possible. In tbat 

caw the ADM issues a CRL which lists the AD device certificate belonging to that device, 

AD Devices Membership Check 

Ihe devices can check that they are in the same AD as another one. This is achieved using 
AD certificates: 

15 1. Device A sends its AD certificate to Device B and vice-versa 
2. Boti devices check the certificates (see next section) 
3* Ifthe certificates are valid) both devices know tliat the otha device is in saxn^ 

Cerdfleate Ch^ Che A 

Ja the second point of the menibecship che6k» both devices will have to check a certificate 
20 diain before declaring that lii0y are in the same AD. dheoks that Device A 

will perform to detenninate if Device B is in the same AD are described below« Device A 
checks (in this order); 

L The AD certificate ofDevice Busing the AD pxsbUc key K^]^ 

2. The AD root certificate usingthepublicdevicekey ofthe ADMK^i^^ 

25 3. The ADM certificate using the pubUc key of the external CAKcARflfltf^^ 

Starting from the root CA, the chain of trust is built in the following ways 

1. The root CA signs the certificate of tiie ADM 

2. The ADM sigM a certificate for a new key pair (AD key pair) with its owe private key 

3. Ihe ADM signs certificates for devices with the AD private key 

30 Content Checkria 

The prerequisite fox content check-«in is that the content and a corresponding right are present 

on the same device. 
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The procedure te: 

1, The device picks up a random symmetric key. I^„dCont encrypts the content with it 

2, The device encrypts K^Rs^ndCow ^tt^.KbwPub checks the ri^t in (see next section) 
3— ThBlleviBg^ertfi&c^ locally 

5 Note that KpertPnb have been used directly for encrypting the content. An 

additional symmetric is chosen, in order to minimize the encryption task, since K^^vPub ^ 
m asymmetric key. Moreovesr, when rij^ts are transfeired (gCTierally together with the 
oontrot), this only implies a r&-encryptlon of the kej^ and not of the rights, which results in 
less processing tasks. 

10 Right Cb6ck~In 

The prerequsitea for right chcck-m aret 

• The contmt and a corresponding ri^t are present on the same device 

* K^dCovt ^ already been chos^ by the device to encrypt the content 

The procedure is: 
15 L The rij^ is traiuslated into an internal AD rcpiese^^ 

internal right identifier. To avoid idaidfier collisions, this identifier must be boimd to the 
device which p^orma the check-in operalian (for mstance to its serial number) 
2. The device add$ tto encrypted version (with K^ey^h) of^K^dOont ^ ^^t and an AD 
identiifi^ (for histance the AD Root Certificate) 
20 ,. 3. ..The device sigQs.the.rightushig^.K^ 

4. The device stores the right. This right contains an internal representation as well as the 
complete external ri^t to enable flirflier export to other systems or ADs. The ettemal 
right is encrypted wifli B^ndCont 

The ri^t is bound locally to a specific device. When a right is transfened, its 
25 secret parts must be re-encrypted with lhe public key of the destination device. 

Con^ntplay . . _ . ^ 

A content play operation is defined as the rendering action performed on a device* The 

content play operation is defined as follows: 
1. The device retrieve the content and a corresponding right &o^ 
30 2. The device checks the right validity 

3« Ifthe right is vaHd» the device d6(^1& the symmetric]^ 
content (I^^coni) AD private key (Kt^^^^v) 
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4, The device deoiyptstlie content vd&K^dc^ 

5. If Hie right is subject to manber coiuit limitations (such as '*play N times'On it is updated 
and ttuBn signed as during rij^t €±ecb;-xn 

Bight Intetpretation 

5 A right interpretation occurs every time a render operation is perfoimed on 

content and when a right i3 copied or moved. It consists in determining the right validity and 
Ihe operations that can be perfoimed on the right itself. 

The inteipretation is performed in the follo^ying steps: 

1. The device checks the right Integrity by nsingK^jcvPab 
10 2, Ifthe right is not authentic, the device stops the ird«ip^ 

3. If the right is authentic, the device int^rets it to find if the content can be processed 

4, If the content can be processed, the device decrypts and delivers the encryption key 
KRandcont ^ the content processor using its private key IS^^j^ 

Sight Update 

IS A ri^t update occurs when a right has some nmnbor count limitations and that the 
conre^onding content is processed. The tqidate process is defined as follow: 

1 . The device which processes the content updates the right appropriately (in a conspliant 
way) 

2. If the right is no longer valid, it is checked out 

20 3* OflbjQrwise, the device conqjutes a hash of Ihe new rigto 

4. The device replaces the old signed hash by the new one in the right 

It should be noted that the above-mentioned embodiments illustrate rafiier than 
Kmit the invention, and that those skilled in the art will be able to design many alternative 
embodimmts without departing firom the scope of the appended claims. 

25 In the claims, any reference signs placed between parentheses shall not be 

constmed as limiting the claim. The word "comprising" does not eKclude the pr^ence of 
elements or st^s other than those listed iii a claim. The word "a" or "an" preceding an 
element does not exclude the presence of a plurality of such elements. The invention can be 
unplemented by means of hardware comprising several distinct elements, and by means of a 

30 suitably programmed coniputcr. 

In the device claim enumerathig several moans, several of these means can be 
embodied by one and lhe same item of hardware. The mere fact tiiat certain measures are 
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tedted in mmmy different depemteot claims does not indicate that a combinatioii of tbesd 
measuzes cannot be u^ed to advantage. 
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CXAIMS: 



1. A digital zighls managemoat syst^ substemtially as set out above. 

2. A device fai use in the distal ngSsSa xoaa&gpassiA system of claim 1. 

5 3. A certificate chain substantially as set out above with reference to Hg. 8. • 
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ABSTI^CT; 



The invention mainly dhiaraoterizes itself through fhe use of a specifio 
c^ttifioate 6hain that governs device compliancy and domain (de)reglstration. This specific 
$Qt-xxpo io. combination with the strict separation betv^een content and licenses, also allows a 
large number of domain operations without interference of the domain manager, and as such 
5 supports different distnbution schemes, such as for example super distribution. 
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DEVICE 

CA Root Certificate (KcARootPub)KcARootPrtv 
Device Certificate (KDevPub)KcARootPriv 
Device Public Key: Koevpub 
Device Private Key: Kpg^^iv 

FIG.9 



DEVICE 



CA Root Certificate (KcARoatPub)KcARootPrtv 
Device Certificate (KDBvPgb)KcAFtodPriv 
Device Public Key: K^e^^i, 
Device Private Key. K^^^^ 



ADM Device Certificate (KADMPub)KcABo«jtpiiv 
AD Root Certificate (KAD.puB)KADMPr.v 
AD Device Certificate: (KD^^b)KAD^rtv 
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